Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_0799/513

Internet Message Format | 1994-08-27 | 1.7 KB

Date: Sat, 25 Sep 93 19:45:55 -0400
From: "Nicholas S Castellano" <[e-mail]>
To: [e-mail]
Subject: read() and POSIX compliance


I've been putting some thought into making the MiNT library's read()
function POSIX compliant.

As it currently stands, the call will return 0 for a read on a device
if the device is positioned at end-of-file, or if the file handle is
marked O_NDELAY and no data is ready.

POSIX introduces the O_NONBLOCK flag which causes the read() to return
-1 with errno set to EAGAIN, when the file has no data available but
is not an end-of-file condition.

I'm thinking along these lines:
  -call Fcntl(fd, &nbytes, FIONREAD)
  -call Fread(...)
  -if Fread() returns 0:  then if nbytes is 0 return -1 with errno =
    EAGAIN, otherwise return 0 signifying end-of file.

This seems valid for the TOS filesystem (since it always gives 1 for
FIONREAD it will never give EAGAIN) and for the pipefs (which will
give -1 for FIONREAD at end-of-file [that is, when the other side of
the pipe is closed] and 0 if there is just no data ready).

This reasoning breaks down, however, in the case of a device such as
the shmfs.  This device will give 0 bytes for an FIONREAD when at
end-of-file, so using the above scheme would mean a non-blocking
read() on shmfs would never return 0.

I'm a bit stumped.  I think it will be necessary to define the exact
action of FIONREAD at end-of-file for device drivers in some
consistent manner in order to make it possible to distinguish EOF from
a lack of available data.

Or am I just overlooking something?

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      [e-mail]
MiNT library mail:  [e-mail]